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BACKGROUND OF THE INVENTION 

1. Technical Field 

The present invention relates generally to telecommunication systems. In particular 
1 5 the invention concerns routing and controlling the flow of packet data transmissions 
in a mobile network. 

2. Discussion of Related Art 

3GPP (3 rd Generation Partnership Project) has recently published a specification for 
20 the 3 GPP system comprising either UTRAN (UMTS Terrestrial Radio Access 
Network) or GERAN (GSM/EDGE Radio Access Network) as a radio access 
network. The specification defines a new broadcast/multicast service titled MBMS 
(Multimedia Broadcast/Multicast Service) [1]. MBMS basic architecture is 
illustrated in figure 1 wherein CBC (Cell Broadcast Center) 102, CSE (Camel 
25 Service Environment) 108, OSA/SCS (Open Service Access) 112 and related 
reference points can be considered as optional functionalities. Accordingly, 
mandatory components for realizing a MBMS service are described next in reference 
to [2]. 

30 The SGSN (Serving GPRS Support Node) 120 executes user specific service control 
functions, concentrates individual users of the same MBMS service into a single 
MBMS service and maintains a single connection with the source of the MBMS 
data. The SGSN 120 may also authenticate users and authorize the usage of services 
based on subscription data from the HLR (Home Location Register) 106. The GGSN 

35 (Gateway GPRS Support Node) 122 terminates the MBMS GTP (GPRS Tunneling 
Protocol) tunnels from the SGSN 120 and links these tunnels via IP (Internet 
Protocol) multicast with the MBMS data source. The BM-SC (Broadcast/Multicast 
Service Center) 110 is an MBMS data source. The architecture also accepts other 
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MBMS broadcast/multicast data sources and internal data sources 104 may directly 
provide their data. Data delivery by external sources 126 is controlled by Border 
Gateways (BG) 124 which may allow for example data from single addresses and 
ports to pass into the PLMN (Public Land Mobile Network) for delivery by an 
5 MBMS service. MBMS data may be scheduled in the BM-SC 110, for example, to 
be transmitted to the user every hour. It offers interfaces which can be utilized by a 
content provider 104, 1 14 in requesting data delivery to users. The BM-SC 110 may 
authorize and charge the content provider 104, 114. The Gmb reference point 
between BM-SC 110 and GGSN 122 enables the BM-SC 110 to exchange MBMS 
10 service control information with the GGSN 122. The Gmb reference point exists in 
order to carry the MBMS service information but it may not always be necessary to 
use the Gmb for each service. MBMS service can be delivered to user equipment 
(UE) 1 16, 128 such as a mobile terminal over GERAN 130 or UTRAN 118. 

15 The architecture assumes the use of IP multicast at the reference point Gi. The 
MBMS data source has only one connection to the IP backbone. The reference point 
from the content provider to the BM-SC 1 10 is currently not standardized as it might 
become too complex or restrictive for service creation. For example, this may be a 
reference point between the BM-SC 110 and an authoring system, or the authoring 

20 functionality may be distributed between both entities. The same architecture 
provides MBMS broadcast services mainly by using the transport functions. The 
user individual SGSN functions are not required. Instead each individual broadcast 
service is configured in the SGSN 120. 

25 The SGSN 120 may use CAMEL (Customised Application for Mobile network 
Enhanced Logic) to handle pre-paid services, e.g. credit checking for on-line 
charging. The Cell Broadcast Center (CBC) 102 may be used to announce MBMS 
services to the users. The BM-SC 110 may exploit OSA-SCS 112 to interact with 
third parties. For the terminal split, MBMS shall be able to interoperate with an IP 

30 multicast client software on the terminal. More detailed information about MBMS 
service activation/release models, data transfer, functionalities of network elements, 
radio interface bearer set-up/release, QoS (Quality of Service), security issues etc. 
can be found in the references [1] and [2]. 

35 As depicted in figure 1, GERAN 130 can be connected to the core network either 
through Iu or Gb interface. Iu interface connects the GERAN 130 to 3G SGSN 120. 
The protocols and the functional split between the radio access network and the core 
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network are in that case the same for UTRAN 1 1 8 and GERAN 1 30. See figure 2 for 
the illustration of user plane protocol stack in Iu mode. Packet Data Convergence 
Protocol (PDCP) maps higher-level characteristics onto the characteristics of the 
underlying radio-interface protocols thus providing protocol transparency for higher- 

5 layer protocols. GPRS Tunnelling Protocol for the user plane (GTP-U) tunnels user 
data between UTRAN and the 3G SGSN, and between the GSNs in the backbone 
network. GTP encapsulates all PDP (Packet Data Protocol) PDUs (Protocol Data 
Unit). UDP/IP (User Datagram Protocol, Internet Protocol) are the backbone 
network protocols used for routing user data and control signalling. The RLC (Radio 

10 Link Control) protocol provides logical link control over the radio interface. There 
may be several simultaneous RLC links per terminal. Medium Access Control 
(MAC) controls the access signalling (request and grant) procedures for the radio 
channel. 

1 5 The Gb interface on the other hand connects the GERAN 130 to 2G SGSN 120 and 
the functional split between the BSS 130 (Base Station System, -radio access 
network e.g. GERAN) and the SGSN 120 is different from the UTRAN/GERAN Iu 
mode. For example, ciphering is done in the core network (SGSN). Also the protocol 
architecture illustrated in figure 3 being described more thoroughly later in the text 

20 and the procedures between the SGSN and the BSS differ from the Iu case. 

As the MBMS standardization work has so far been mainly focused on the Iu 
interface, the procedures presented in the architecture and functional description [2] 
are applicable only for UTRAN/GERAN Iu mode. Therefore, new functionality is 

25 needed if MBMS service is introduced into GERAN Gb interface. One specific 
problem is that with Gb interface there is no RAB (Radio Access Bearer) concept in 
the same way as in the Iu interface. Thus the procedures corresponding to the 
MBMS RAB setup, release etc. do not apply to the Gb interface. The SGSN 
establishes RABs basically on demand when there exists data to be transferred to the 

30 users. 

An option for MBMS (broadcast) service activation and RAB set-up is presented as 
an illustration in figure 4 in reference to [2]. At a SGSN re-start or when a new 
MBMS broadcast service is set-up, see phase 402, the SGSN 120 requests a creation 
35 of an MBMS context and GTP tunnel on the GGSN 122 for each RNC/BSC (Radio 
Network Controller, Base Station Controller) within the service area. In phase 404 
the GGSN 122 joins the relevant IP multicast to connect the BM-SC 110 if not 



3 



connected already. In phase 410 the GGSN confirms the establishment of the 
MBMS context. In phase 412 MBMS data is sent to the GGSN 122 and in phase 414 
forwarded to the SGSN 120 through all related Gn/Gp tunnels. In phases 416 and 
418 a RAB (Radio Access Bearer) is created for each MBMS context by utilizing 
5 assignment request and response procedures. In phase 420 MBMS notification is 
sent to terminals being finally followed by the transmission of actual MBMS data in 
phases 422 and 424. In a corresponding multicast case (not shown), the terminal 
first transmits an Activate MBMS Context Request to the SGSN 120. The IP 
multicast address identifies the MBMS multicast service, which the terminal wants 

10 to join. The SGSN 120 validates the Activate MBMS Context Request. The MBMS 
context(s) store the parameters of the activated MBMS multicast service. If said 
terminal is the first one activating this specific MBMS multicast service on the 
routing area, the SGSN 120 determines the RNCs serving the routing area and 
requests for each the creation of an MBMS context on the GGSN 122 and the 

1 5 establishment of a GTP tunnel between the SGSN 120 and the GGSN 122. Later in 
connection with the RAB set-up, the SGSN 120 sends MBMS RAB Request 
(indicating e.g. QoS parameters) only to the RNCs serving the Routing Areas in 
which there are terminals which have joined the MBMS context. 

20 In addition to arrant data delivery issues, also other aspects remain open in 
exploiting the Gb interface. For example, various applications must not interfere 
with each other when the BSS 130 schedules the data transfer over the air interface. 
Normally both the SGSN 120 and BSS 130 have data buffers for data transmission. 
If the data buffer in the BSS 130 fills up because of an overwhelming data flow by a 

25 certain MBMS service, the transmission of other services using the same data 
transmission buffer is also negatively affected (transmission delays etc). This is one 
issue that must be taken into account if MBMS is introduced to the GERAN A/Gb 
mode as currently expected. 

30 DISCLOSURE OF INVENTION 

An object of the present invention is to alleviate the aforesaid deficiencies and 
provide an addressing mechanism for routing MBMS data over the Gb interface 
between the SGSN 120 and BSS 130. Additionally, a flow control mechanism is 
35 needed for MBMS services as the bitrate they typically require may be relatively 
high and varying causing potential problems also for other traffic delivered by the 
BSS 130. The object is achieved by introducing a concept of MBMS-specific packet 
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flow context (PFC), called MBPFC (Multicast/Broadcast Packet Flow Context) 
hereinafter, to the Gb interface with functionalities partly corresponding the ones 
MBMS RAB provides in the Iu mode. The proposed concept thus allows reuse of 
some already-existing procedures and resolves certain Gb interface specific 
5 problems. 

The term "BSS" (Base Station System) refers to a radio access network, e.g. a 
GERAN, comprising at least one base station and radio network controller / base 
station controller. 

10 

The term "Gb" refers to an interface between the BSS and second-generation packet- 
switched core network. 

A method according to the invention for routing MBMS (Multicast/Broadcast 
15 Multimedia Service) service data from a first network entity to a second network 
entity is characterized in that the method has the steps of 

-defining a packet flow identifier (PFI) associated to at least one MBMS 
service or a group of terminals, 

-creating a packet flow context (PFC) for said MBMS service or group of 
20 terminals identified by said PFI, 

-transferring the MBMS service data over the Gb interface by utilizing said 
PFC. 

In another aspect of the invention, a system comprising a Gb interface between a 
first and a second network entity, is characterized in that in order to route MBMS 
25 service data over said Gb interface said first and second network entities are 
arranged to negotiate a common packet flow identifier (PFI) for said MBMS service 
or a group of terminals and said second network element is arranged to create a 
packet flow context (PFC) for said service or group of terminals. 

In a further aspect of the invention, a device functionally connected to a Gb 
30 interface, is characterized in that in order to route MBMS (Multicast/Broadcast 
Multimedia Service) service data over the Gb interface it is arranged to define a 
packet flow identifier (PFI) associated to at least one MBMS service or a group of 
terminals, to create a packet flow context (PFC) for said MBMS service or group of 
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terminals identified by said packet flow identifier, and to transfer the MBMS service 
data over the Gb interface by utilizing said packet flow context. 

Such a device may be e.g. a network element such as the SGSN operable in a 
second-generation packet-switched core network and comprise standard processing 
5 (e.g. processor, micro-controller, signal processor, programmable logic), memory 
(e.g. one or more memory chips) and data transfer means (e.g. fixed data interface 
with controller) configured to execute the method of the invention. 

The accompanying dependent claims describe embodiments of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 In the following, the invention is described in more detail by reference to the 
attached drawings, wherein 

Fig. 1 is a block diagram of an MBMS capable system. 

Fig. 2 is a block diagram of the protocol architecture (user plane) in Iu mode. 
Fig. 3 is a block diagram of the protocol architecture (user/control plane) in 
A/Gb mode. 

Fig. 4 is a signalling chart disclosing one option for MBMS Broadcast 
service activation and RAB set-up. 

Fig. 5A is a signalling chart disclosing the messaging applied in the creation 
of MBPFC. 

Fig. 5B is a signalling chart disclosing the messaging applied in the deletion 
of MBPFC. 

Fig. 6 illustrates an option for the message structures applied in the MBPFC 
creation and deletion. 

Fig. 7 presents the layers for controlling the flow of MBMS data routed over 
the Gb interface. 

Fig. 8 discloses a flow diagram of a method for routing and controlling the 
flow of MBMS data in accordance with the invention. 

30 BEST MODE FOR CARRYING OUT THE INVENTION 

Figures 1-4 were already covered in conjunction with the description of the prior art. 
The signalling chart in figure 4 presenting the MBMS service activation is feasible 
also in this case when it comes to phases 402-414 preceding the RAB set-up. 
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The protocol stack of the Gb interface as depicted in figure 3 contains layers titled 
BSSGP (BaseStation System GPRS Protocol) and Network Service (NS). BSSGP 
controls the transfer of LLC (Logical Link Control) frames passed between an SGSN 
5 and a terminal across the Gb interface. Accordingly, the primary functions of the 
BSSGP include the provision by an SGSN 120 to a BSS 130 of radio related 
information used by the RLC/MAC function, the provision by a BSS 130 to an 
SGSN 120 of radio related information derived from the RLC/MAC function and the 
provision of functionality to enable two physically distinct nodes, an SGSN 120 and 
10 a BSS 130, to operate node management control functions. BSSGP Virtual 
Connections (BVC) provide communication paths between BSSGP entities. BVCs 
are identified by means of a BSSGP Virtual Connection Identifier (BVCI) which has 
end-to-end significance across the Gb interface. Each BVCI is unique between two 
peer Network Service Entities. The Network Service is the entity which actually 
15 provides network service primitives allowing the transmission and reception of 
upper layer protocol data units between the BSS 130 and SGSN 120. The Network 
Service is based on the Frame Relay (FR) connection between the BSS 130 and the 
SGSN 120, and may multi-hop and traverse a network of Frame Relay switching 
nodes. Each Network Service Entity is identified by means of a Network Service 
20 Entity Identifier (NSEI) which together with the BVCI uniquely identifies a BSSGP 
Virtual Connection within an SGSN 120. The SGSN 120 needs not to be updated 
when a new cell (BVC/BVCI) is added to the BSS (NSEI) 130. The NSEI is used by 
the BSS 130 and the SGSN 120 to determine the NS-VCs that provide service to the 
BVC. Logical Link Control (LLC) offers a ciphered logical link being independent 
25 of the underlying radio interface protocols in order to allow introduction of 
alternative GPRS radio solutions with minimum changes to the NSS. RLC/MAC 
contains two functions: The Radio Link Control function provides a radio-solution- 
dependent reliable link. The Medium Access Control function controls the access 
signalling (request and grant) procedures for the radio channel, and the mapping of 
30 LLC frames onto the physical channel. See the references [3], [4] and [5] for further 
details about GPRS protocol stacks, PDUs, BSS contexts, flow control as well as 
common GPRS attach/detach and PDP context activation/deactivation procedures. 

The SGSN 120 can provide the BSS 130 with information related to ongoing user 
35 data transmission. The information related to one terminal is stored in a BSS 
context. The BSS 130 may contain BSS contexts for several terminals. A BSS 
context contains a number of BSS packet flow (PFC) contexts. A PFC is created 
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with DOWNLOAD-BSS-PFC (optional), CREATE-BSS-PFC and CREATE-BSS- 
PFC-ACK PDUs as described in the reference [4]. A BSS packet flow context (PFC) 
is identified by a packet flow identifier (PFI). There are four pre-defined packet 
flows identified by four reserved packet flow identifier values. One predefined 
5 packet flow is used for best-effort service, one for signalling, one for SMS (Short 
Message Service), and one for LCS (Location Services). The BSS 130 shall not 
negotiate BSS packet flow contexts for these pre-defined packet flows with the 
SGSN 120. 

10 The flow control mechanism manages the transfer of BSSGP UNITDATA PDUs 
sent by the SGSN 120 over the Gb interface to the BSS 130. There is a downlink 
buffer for each BVC in the BSS 130 identified by a BVCI. UNITDATA PDU 
contains an LLC PDU to be transmitted across the radio interface to a terminal. The 
principle of the existing BSSGP flow control procedures is that the BSS 130 sends 

15 flow control parameters to the SGSN 120 thus allowing the SGSN 120 to locally 
control its transmission output in SGSN to BSS direction (flow control is used only 
in the downlink direction). There are different levels of flow control: PFC, MS 
(Mobile Station; corresponding to a terminal) and BVC level. The SGSN 120 shall 
always apply BVC and MS flow control whereas PFC flow control is optional. The 

20 BSS 130 controls the flow of UNITDATA PDUs to its BVC buffers by indicating to 
the SGSN the maximum allowed throughput for each BVC in a FLOW-CONTROL- 
BVC PDU. The BSS 130 controls the flow of UNITDATA PDUs to the BVC buffer 
of an individual terminal by indicating to the SGSN 120 the maximum allowed 
throughput for a certain TLLI (Temporary Link Level Identity) with FLOW- 

25 CONTROL-MS PDU. Additionally, FLOW-CONTROL-PFC PDU provides the 
SGSN 120 the flow control information regarding one or more PFC(s) of a given 
terminal. The SGSN 120 applies first PFC (if negotiated), then MS and finally BVC 
level flow control. If an LLC PDU to be included in a UNITDATA PDU passes all 
applied levels of flow control it is forwarded to lower protocol layers to be 

30 transferred to the BSS. 

Figures 5-7 disclose one option for enabling MBMS data routing and flow control 
between the SGSN 120 and BSS 130 in accordance with the invention. In a general 
sense, a procedure partly congruent with the PFC concept described above can be 
35 applied by creating a MBPFC for each MBMS service, a group of services or a 
group of terminals. From the SGSN's standpoint said group of terminals may, for 
example, belong to a same multicast group and reside behind a common BVC. The 



group, which typically contains at least two terminals, may receive data from a 
single source, e.g. an MBMS service, or from multiple sources. Occuring randomly 
it is still possible to have only one user (-one terminal) in the group though. In any 
case, the MBPFC is not logically connected to any individual terminal/associated 
5 with any individual TLLI (or TMSI / P-TMSI). In a multicast scenario the group for 
which the MBPFC is logically connected may be identified by a specific ID (e.g. a 
multicast ID). An MBMS specific PFI such as the multicast ID can also be sent to 
the terminals belonging to the multicast group for identifying the incoming MBMS 
flow. However, this may not be necessary as the identification can also be done in 

10 some other way (MBMS ID etc). The main use of an MBPFC is according to the 
invention to serve as an addressing mechanism between the SGSN 120 and the BSS 
130 and facilitate using flow control in the Gb interface. In the BSS 130 the MBPFC 
is mapped to an appropriate logical channel so that the announced MBMS service is 
sent on the channel indicated to users in the service announcement procedure, 

15 wherein network broadcasts information e.g. about the frequency, time slot, and 
possibly TDMA frame when a particular service is scheduled over the radio 
interface. 

The creation of an MBPFC can be executed as follows, see figure 5A. The SGSN 

20 120 may initiate the procedure without any specific trigger from the BSS 130 side. 
For example, when the network establishes a new MBMS service or when the data is 
actually to be transferred the SGSN 120 initiates the creation of an MBPFC relating 
to the service/multicast group. This can be done in conjunction with the service 
announcement or later on. The SGSN 120 requests for the creation of the MBPFC by 

25 sending a CREATE-MBPFC PDU 504 to the BSS 130 including a PFI to be used for 
the PFC identification. The BSS 130 (in the GERAN case the network elements 
within the BSS executing this task are the RNCs), responds with a CREATE- 
MBPFC-ACK PDU 508 or corresponding NACK if the MBPFC cannot be created. 
As the proposed method is reminiscent of the one for creating a standard PFC with 

30 DOWNLOAD-BSS-PFC (optional), CREATE-BSS-PFC and CREATE-BSS-PFC- 
ACK messages, the existing standard procedure can also be exploited in this MBMS 
specific case, anyhow recalling that the essential difference is founded on a fact that 
the MBPFC is not logically connected to an individual terminal unlike the standard 
PFC. The network maps the PFC/PFI to a MBMS service/multicast group and it is 

35 also possible, although not advisable, to position all MBMS services into a single 
MBPFC. In that case different services cannot be treated independently and they may 
delay each other etc. The SGSN 120 and BSS 130 maintain entities, e.g. memory 
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tables, of existing MBMS service/multicast group<->PFC/PFI mappings in order to 
route and control the flow of the data to be transferred and, in the BSS 130, to 
further pass the received data over an appropriate (e.g. announced) logical channel to 
terminal(s) either as a broadcast or PTM (Point-To-Multipoint, e.g. multicast) 
transmission. 

Figure 6 discloses an option for the structure of messages applied in the figure 5A. 
CREATE-MBPFC PDU 504 includes fields for a message type identifier 602 e.g. a 
PDU type, PFI 604, ABQP 606 which is an Aggregate BSS QoS Profile (ABQP) 
defining the QoS agreed for the PFC (see the reference [5]) and optional data 608 
such as optional IDs or group (e.g. terminals belonging to the same multicast group) 
definitions/identification etc. CREATE-MBPFC-ACK PDU 508 includes 
corresponding fields for a type identifier 610, a PFI 612 and ABQP 614 that may be 
restricted by the BSS 130 based on its current status and capabilities. 
Correspondingly, if NACK message is transmitted instead of ACK, a cause field can 
be included in the NACK to indicate the specific reason for rejecting the MBPFC 
creation as in a standard PFC case described in the reference [4]. 

MBPFC deletion can be executed respectively, see figure 5B. The SGSN 120 
requests the deletion when e.g. the service delivery has been ceased by transmitting a 
message DELETE-MBPFC 512 to the BSS 130 that acknowledges the request with 
DELETE-MBPFC ACK 516. It's also possible that the BSS 130 deletes the MBPFC 
for some reason (e.g. lack of data transfer, memory or processing resources) and then 
informs the SGSN 120 about the executed deletion with a message, e.g. DELETE- 
MBPFC ACK 516. The message internals are not described here as they are mostly 
in conformity with the ones presented for the creation of an MBPFC including at 
least a message ID and TFI for the identification purposes. 

The SGSN 120 shall preferably perform flow control on each BVC, on each MBPFC 
and on some/all MBMS services as a whole, see figure 7. The flow control is 
performed first on each LLC-PDU (to be included in a UNITDATA PDU) by an 
MBPFC specific flow control mechanism 702, then by an aggregate flow control 
mechanism 704 and finally by a BVC flow control mechanism 706. BVC flow 
control (typically corresponding a cell) parameters concerning both standard PFCs as 
well as MBPFCs are received from the BSS 130 in a FLOW-CONTROL-BVC PDU 
described in the reference [4]. MBPFC flow control parameters can in principle be 
received from the BSS in a FLOW-CONTROL-PFC message as in a normal PFC 
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case but the binding of the PFC with an individual terminal does not naturally apply. 
However, the BSS 130 may, for example, estimate an average profile of terminals 
receiving the services and inform the profile or relating parameters to the SGSN 120 
for derivation of MBPFC specific flow control definitions. On the other hand, a set 
5 of rules may have been programmed in the BSS 130 indicating desired parameters 
(e.g. limit values for data leakage) for receiving services of varying types and based 
on that information, provide MBPFC specific parameters to the SGSN 120. As an 
third option, the SGSN 120 may define MBPFC flow control parameters based on 
some service related data or its current status (e.g. load). An entity called MBMS 

10 service block 708 may be created, under which there would be a number of MBPFCs 
carrying different MBMS services, to form an aggregate flow control level 704 
comprising at least one block 708 but one option is to perform only PFC and BVCI 
flow control resulting that the aggregate level 704 in figure 7 does not exist. 
Secondly, if only a single PFC is created for all MBMS services as mentioned 

15 earlier, the situation remains the same. The SGSN 120 may construct the MBMS 
service blocks 708 by, for example, dividing the MBMS services into a number of 
groups (linked to blocks) based on the information about service/content type, 
content provider and service delivery requirements. This information, which can also 
be utilized in the creation of MBPFC flow control definitions, may be received, from 

20 a network element like the GGSN 122 or it can be derived internally either explicitly 
or implicitly from the MBMS data or relating ancillary information. 

A method applying the principles described hereinbefore is presented in figure 8. 
First, at a MBMS service start-up 802 or, for example, when the SGSN 120 has 

25 actually received data to be delivered to terminals, a PFI is defined 804 for the 
service identification and a corresponding PFC (MBPFC) is created 806 in the BSS 
130, assigned by the SGSN 120. In practice, the order of phases 804 and 806 is not a 
relevant issue as long as the MBPFC and PFI are created as a result. Next, the radio 
resources between the BSS and terminals are reserved and set up in phase 808. This 

30 phase may include transmitting of MBMS notifications. Flow control is performed 
810 before transferring the data over the Gb interface 812 from the SGSN 120 to the 
BSS 130 and finally over the air interface 814 to the terminals. If more data appears 
to be delivered 816 the phases of flow control 810 and data transfer 812, 814 may be 
repeated. When no more data exists, for example, for a predetermined time period or 

35 the service is ramped down, the MBPFC may be deleted 818. It should be noted that 
the order of the aforementioned phases may be changed and some phases can even 
be altered or combined together without diverging from the concept of the invention. 

11 



For example, phase 808 may be executed just before phase 814 if logical 
channels/radio resources are to be allocated in connection with actual data delivery. 

The scope of the invention is disclosed in the following independent claims. 
5 However, utilized messages, network elements, method and procedural steps, etc., 
may vary depending on the current scenario, still converging to the basic ideas of the 
invention. Therefore, the invention is not strictly limited to the embodiments 
described above. 
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